Subject: Standard DLSw MIB progress

From: [email-masked]
Date: Mon, 18 Apr 94 12:21:52 EDT

At the February AIW, I suggested 4/15 (Friday) as a target for pulling
together different MIB elements (which we would have discussed on this
mailing list) into an initial draft MIB.  While I haven't had the time
so far to lead an e-mail discussion on this, we have within IBM had a
few discussions about objects for a standard MIB.  I don't know whether
the same thing has been happening at other companies or not.

Rather than waiting to have a full-blown MIB ready to introduce, I
thought it might be best to have some e-mail discussion on general
topics.  Below are some of the issues I think the RIG needs to
start to discuss - please add your comments.  If some company is
planning to submit a whole MIB for discussion, please let me know.

1) Documentation plan
   I raised as a question at the last AIW how we should fit the MIB in
   with the draft RFC Alan Bartky is editing.  Since then I've talked
   with several people and we have the IETF's view.  So far everyone seems
   to feel that the MIB should be a separate document from the protocol.
   This makes sense to me, since there's a well-understood format for
   a MIB RFC.  It also allows the two to be on a slightly different
   schedule for whatever standards track(s) we pursue.  If everyone
   feels ok about this, I think IBM could provide the editor.

2) Standard traps
   Notwithstanding Shannon's helpful response to my poll on this
   mailing list about standard traps, I am inclined to conclude there's
   not a lot of interest in them.  I am assuming we'll all concentrate
   our efforts on the MIB for now.

3) MIB structure issues
   I suggest the following general structure, along the lines I
   outlined at the AIW meeting.  We can discuss specific objects
   later, this is just for structure.

   Reporting node objects
     Objects for this node's capabilities
     Objects for common sysdef'd parameters (e.g., ring num, IP addr)
     Objects for current box-level DLSw status
   Partner router table (1 per box, row per sysdef'd or actual partner)
     Objects for sysdef & oper status of each partner
     Objects for capabilities of partner ??
   SDLC station table (1 per SDLC port, row per station)
     Objects for DLSw-specific sysdef'd info about SDLC stations
     Objects indexing/pointing to corresponding SDLC MIB entry
   Circuit table (1 per box, entry per DLC connection using DLSw)
     Objects for DLSw-specific addresses, states, etc.
     Objects indexing/pointing to corresponding DLC MIB entry
   Cache table (1 per box, entry per router/target pair)
     Objects for router / target (mac addr / NB name) associations

   The idea is not to duplicate info in a "DLC MIB", which can be:
     - the SDLC MIB or LLC MIB when they are standardized
     - a vendor-specific MIB of the DLC info they keep
   The following questions come to mind, in addition to the general
   question "is the overall proposed structure ok?".

   a) Should a partner router table entry contain any info learned
      about a partner from capex?  Or should the philosophy be that
      the management station should go to the partner box directly
      for info on its capabilities?  Note that we have to store this
      information anyway.
   b) The SDLC station table is where I would put mappings between
      SDLC station and MAC/SAP addresses.  They don't belong in the
      DLC MIB, in my opinion.  Is this plan ok?  Does anyone feel
      a need for an LLC station table for sysdef'd info that is
      specific to DLSw and not LLC itself?
   c) As defined, the circuit table would have 2 entries for a "local"
      DLSw connection - does this seem reasonable to everyone?
   d) What circuit states should the circuit table cover?  It is
      natural to show established circuits and this would be useful
      for traffic stats and performance info, but not for PD on why
      a circuit does not come up.  What do people want to use the
      table for?
   e) To get to cache information, should we generalize a cache entry
      concept (e.g., with MAC addr / NB name "key" and short "reachable
      through" IP address list)?  Is there a better way to get access
      to "reachability" or topology information, or should we drop
      this table as overkill?

Peter Gayek
IBM Corp.